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VALUES AMD OBJECTS IN PROGRAMMING LANGUAGES* 
B. J. MacLennan 
81/04/13 



1. INTRODUCTION 



The terms va 1 ue - or i ented and object - oriented are used to 
describe both programming languages and programming styles. This 
paper will describe the differences between values and objects 
and to show that their proper discrimination can be a valuable 
aid to conquering program complexity. The first section will 
sho\/ that values amount to timeless abstractions for which the 
concepts of updating, sharing and instantiation have no meaning. 
The second section v/i 1 1 shov/ that objects exist in time and, 
hence, can be created, destroyed, copied, shared and updated. 
The third section shows that proper discrimination of these con- 
cepts in programming languages v/ill clarify problems such as the 
role of state in functional programming. The paper concludes by 
demonstrating the use of the value/ object distinction as a tool 
for program organization. 



* The v/ork reported herein \/as supported by the Foundation 
Research Program of the Naval Postgraduate School with funds 
provided by the Chief of Naval Research. 
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2. VALUES 



Values are a p p 1 i c a t i v e . The term value - on'ented is most 
often used in conjunction with a p p 1 i c a t i v e programming, that is, 
v/ith prograirimi ng with pure expressions and without the use of 
assignment or other i mperat i ve facilities. Another way to put 
this is that val ue- or i ented programming is programming in the 
absence of side-effects. This style of pro grammi ng is important 
because it has many of the advantages of simple algebraic expres- 
sions, viz , that an expression can be understood by understand- 
ing its constituents, that the meaning of the subexpressions is 
independent of their context, and that there are simple inter- 
faces between the parts of the expression that are obvious from 
the syntax of the expression. For instance, in 1 + (x-y)/z, the 
meaning of the entire expression is only dependent on the mean- 
ings of 1 and (x-y)/z, the meaning of (x-y) is independent of 1 + 
.../z, and the relation between (x-y) and the rest of the expres- 
sion is obvious from the form of the expression. 

Primitive values are the par ad i gms . The idea of values is 
most familiar, as the above discussion indicates, in the realm of 
nurabers. Since numbers have no internal structure, they can only 
be combined by the operations (such as +) to yield other numbers. 
In programming languages the primitive, or atomic, data such as 
integers, reals, Booleans and characters, are usually treated as 
values. These are all operated on by side- effect- free operations 
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that yield other values. Expressions involving values satisfy 
all of the desirable properties listed above (provided they con- 
tain no side-effect producing procedures). These primitive data 
values provide a model for all other values. 

C ompound values are also possibl e. It might seem that 
values are necessarily restricted to primitive data values, since 
a compound data value immediately admits the possibility of 
updating a component of the data value. For instance, arrays 
cannot be considered values because of the possibility of updat- 
ing one component of the array. This is not essential to the 
concept of arrays, however, as we can see by looking at APL. In 
this language it is possible to perform extensive computations 
with arrays without ever performing an assignment. This is 
because the array is treated as a \/hole and, instead of updating 
a component of an array, an entire new array is computed instead. 
To put it another way, in APL expressions arrays are treated as 
values. Of course, this is not true in APL if one uses the 
assignment operation, \/hich does allow updating of array com- 
ponents. A subset of APL without the assignment operator is a 
value-oriented language. 

Another example of a compound value is a complex number. As 
used by mathematicians, these values are operated on by side- 
effect-free operations that produce other complex numbers. Of 
course, it is possible to extract the real and imaginary parts of 
a complex number, or to put two reals together to make a complex 
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number. What is not possible is the selective updating of one 
part of a complex number analogous to the selective updating of 
an array component. 

Pure LISP is another example of a value-oriented language. 
That is, if the PROG feature, EQ, and the RPLACA and RPLACD pro- 
cedures are not used, then LISP lists can be treated as mathemat- 
ical objects and LISP functions have all the desirable properties 
of arithmetic operations. (PROG and the RPLACx functions allow 
updating; EQ allows instances to be distinguished) 

Hoare, in his Recursive Data Structures , has described how 
these ideas can be extended to more general structures. In this 
paper Hoare advocates eliminating the pointer from programming 
languages in favor of recursive definitions of data types. We 
will see later that recursive data types are a natural concommi- 
tant of values and that pointers are closely connected with 
objects. Hoare shows that if data structures are properly res- 
tricted then all pointer manipulation can be performed automati- 
cally. This is advantageous because pointers are a common source 
of errors, a point elaborated below. 

Values are more secure . Consider an expression such as (- 
x)/(x+y)* There is no chance that the operation (-x) on x will 
effect the outcome of (x+y). This is because the thing denoted 
by X is a value and the operation has no si de- effects . That 
is, each part of an expression involving values is independent of 
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all the others. One reason for this is that values are read - 
only , i.e., it is not possible to update their components. Since 
they are unchangable, it is alv/ays safe to share values for effi- 
ciency; there is never any danger of one expression altering 
something v/hich is used by another expression. Any sharing that 
takes place is hidden from the programmer and is done by the sys- 
tem for more efficienct storage utilization. For example, LISP 
systems allov/ final portions of lists to be shared among any 
number of lists. This can never lead to surprising results v/hen 
dealing v/ith values because updating is not allo\/ed. Avoiding 
updating eliminates dangling reference problems and simplifies 
deallocation. 

What are val ues ? We have discussed a number of properties 
of values and have presented several examples of them. What 
exactly are they? The best examples of values are mathematical 
entities, such as integers and real and complex numbers, hence v;e 
may expect to understand values better by understanding these 
better . 

One characteristi c of mathematical entities is that they are 
eternal , in the literal sense of being out of time. To put it 
another v/ay, the concept of time or duration does not apply to 
mathematical entities any more than the concept color applies to 
them; they are neither created nor destroyed. When we write 2+3 
there is no implication that 5 has just come into existence and 
that 2 and 3 have been consumed; mathematical entities are 
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timeless. Similarly, numbers are immutable. When v;e perform the 
operation (l+2i)+5 and get 6+2i , we have not changed l+2i in any 
\iay. It is not as though we had changed its real part from 1 to 
6. What is it about numbers that give them these properties? 

Values are abstractions . The fundamental fact that gives 
mathematical entities and other values these properties is that 
they are abstracti ons , or universals, or concepts. Although a 
full explication of mathematical entities is beyond the scope of 
this paper it should be fairly clear that the number 2 is an 
abstraction that subsumes all instances of "t\/o-ness." That is, 
just as this tree or that tree or another tree are all subsumed 
under the concept 'tree', so also this pair or that pair or this 
other pair are all subsumed under the concept 2. Abstractions 
are universal; the concept 2 subsumes all possible pairs, those 
existing, those in our imagination, those that have existed, 
those that are yet to exist. This universal nature of abstrac- 
tions makes them eternal, or out of time. The number 2 can nei- 
ther be created nor destroyed because its existence is not tied 
to the creation or destruction of particular pairs. Indeed, the 
concept of existence, in its usual sense, is not applicable to 
the number 2. It is the same with all values, because all values 
correspond to abstractions; they can neither be created nor des- 
troyed . 

It is also the case that abstractions, and hence values, are 
immutable. Suppose there is $2 in someone's bank account, we may 
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say there is a pair of dollars in his account. This pair of dol- 
lars is subsumed by the abstraction (value) 2. Now suppose that 
v/e increase the balance to $3. Have we changed the value 2? No, 
there is now a triple of dollars in his account that is subsumed 
by the value 3, but the value 2 is still unchanged; it still sub- 
sumes all the pairs, including that particular pair of dollars 
that no longer exists. Thus, although values may be operated on, 
in the sense of relating values to other values, they cannot be 
altered. That is, 2 + 1=3 states a relation among values; it does 
not alter them. Values are eternal and immutable. 

There is a possible confusion that must be prevented. When 
in a programming language we assign x the value 2, x:=2, and 
later add one to x, x:=x+l, haven't \/e changed a number, which is 
a value? No, we haven't; the number 2 has remained the same. 
What \/e have changed is the number that the name x denotes. We 
can give names to values and we can change the names that we give 
to values, but this doesn't change the values. The naming of 
values and the changing of names is discussed in a later section. 

Values cannot be counted . A corollary of the above is that 
there is not such thing as "copies" of a value. This should be 
clear from mathematics: it is not meaningful to speak of this 2 
or that 2, there is just 2. We say that the number 2 is uniquely 
determined by its value. This is because an abstraction is 
uniquely determined by the things v/hich it subsumes, hence, any- 
thing which subsumes all possible pairs is the abstraction 2. 
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Therefore, the concept 'number' is not even applicable to 
abstractions; it makes no sense to ask hov/ many 2's there are. 
While it may be meaningful in a programming language to make 
another copy of an array, it is pointless to make another copy of 
a value; there is no such thing. There is also no reason to make 
such a copy since values are immutable. (It is, of course, pos- 
sible to make copies of a representation of a value; this is dis- 
cussed 1 ater. ) 

It is also meaningless to talk about the sharing of values. 
Since values are immutable, and can neither be counted nor 
copied, it is irrelevent v;h ether different program segments share 
the same value or different "copies" of the value. Of course, 
there may be implementation differences. If a long string value 
is assigned to a variable it v/i 1 1 make a big difference V'/hether a 
fresh copy must be made or v/h ether a pointer to the original copy 
can be stored. While this is an important implementation con- 
cern, it is irrelevent to the semantics of values. 

Values are used to model abstract! ons . We have discussed a 
number of the characteristics of values but have not discussed 
v^hether values should be included in programming languages, or, 
if they are, what they should be used for. The answer to this 
question lies in the relation \/e have shov/n betv/een values and 
abstractions; values are the programming language equivalent of 
abstractions. Thus, values will be most effective v/hen they are 
used to model abstractions in the problem to be solved. This is 
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in fact their usual use, since integer and real data values are 
used to model quantities represented by integer and real numbers. 
Similarly, the abstraction 'color' may be modeled by values of a 
Pascal or Ada enumeration type, (RED, BLUE, GREEN). Cn the other 
hand, it is not common to treat compound data values, such as 
complex numbers or sequences, as values. If done, this would 
eliminate one source of errors. Nov/, v al ue- or i ented languages, 
such as the languages for data-flow machines and functional pro- 
gramming, have only values. Is there any need for objects at 
all? This is answered in the follov/ing sections. 



3. OBJECTS 



Computi ng can be v i ewed a s simulation . It has been said 
that computing can be viewed as simulation. This is certainly 
obvious in the case of programs that explicitly simulate or model 
some physical situation. The metaphor can be extended to many 
other situations. Consider an employee data base; each record in 
the data base corresponds to an employee. The data base can be 
said to be a simulation, or model, of some aspects of the cor- 
poration. Similarly, the data structures in an operating system 
often reflect the status of some objects in the real v/orld. For 
instance, they may reflect the fact that a tape drive is rev/i nd- 
ing or in a parity-error status. The data structures can also 
reflect logical situations, such as the fact that a tape drive is 
assigned to a particular job in the system. 
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A data structure i s needed for each entity . It should be 
clear that simulation is simplified if there is a data structure 
corresponding to each entity to be simulated; this simplifies the 
programming of the simulation by factoring and encapsulating 
related information. This is exactly the approach that has been 
taken in object-oriented programming languages, such as 
Smalltalk. The usual way to structure a program in such a 
language is to create an object for each entity in the system 
being modeled. These may be real-v/orld objects or objects that 
are only real to the application, such as figures on a display 
screen. The messages these objects respond to are just the 
relevent manipulations that can be performed on the corresponding 
real entities. Given this relationship between programming 
language objects and real world objects, we will try to clarify 
the notion of an object. 

What i s an object ? In cur programming environment we have 
objects and in the real world we have objects. Just what is an 
objct? When we attempt to ansv/er this question we immediately 
find ourselves immersed in age-old philosophical problems. In 
particular, what makes one object different from another? We can 
imagine another typewriter that looks exactly like the one before 
us now, sharing every characteristic and attribute of this type- 
v/riter, except being different. That is, it is easy to imagine 
two instances of the same typewriter. What makes them different 
typewriters? One philosophical answer to this question is to say 
that v/hile the two typewriters have the same form , they have 
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different substance . To put this is more concrete terms, v;e 
could say that the tv/o typev/riters are alike in every viay except 
that they occupy different regions of space. Nov/, vie find 
exactly the same situation arising in programming languages. Vie 
may have two arrays that contain exactly the same values, yet 
they are two different arrays. What make them different? V'e 
v/ould say that they occupy different locations. So by analogy, 
the form of the array is the order and value of its elements 
while the substance of the array is the region of memory it occu- 
pies. 



This i s a. philosophical problem . There is also a less phi- 
losophical way in which we distinguish real v/orld objects: v/e 
give them proper names. For instance v/e can use Sam and Joe as 
the names of identical twins. Even though each of these entities 
is (we can presume) alike in all of its other attributes, they 
can always be distinguished by their names. We find an exactly 
analogous situation in programming languages. Programming 
objects, such as the arrays already mentioned, generally have a 
unique name: the reference to the object. Tdis is generally 
closely related to the region of storage the object occupies. 
This is not necessary, hov/ever, as v/e can see by consdering a 
file system. It is easy to see that files are objects; it is 
quite normal to have tv/o different files with the same contents. 
Of course, if the files are to be distinguished, then they must 
have distinct names. Incidently, it will also be the case that 
they occupy distinct areas of the storage system a fact that v/e 
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can test by updating one file and observing that the other 
doesn't change. Nov/, for our purposes, we will not be too con- 
cerned about what individuating element is used; v/hether it is 
some form of unique identification (such as a capability), or 
whether it is implicit in the region of storage occupied; we will 
assume that each object is different from every other object even 
if they contain the same data values. Thus there may be any 
number of i nstances of otlierwi se identical objects. This leads 
to a number of further consequences. 

Objects can be changed . Nov/ v/e have said that the identity 
of an object is independent of any of its internal properties or 
attributes. For instance, even if all of the elements of an 
array are changed, it is still the same array (because it occu- 
pies the same region of storage). This is of course like real 
world objects, for they too can change and retain their identity. 
Values, on the other hand can never change. For instance, if we 
add 5 to l+2i , we don't change l+2i , we produce a new value, 
6 + 2i. This changab i 1 i ty , this fact that an object may have one 
set of properties at one time and a different set at another 
time, is a distinctive feature of objects (and of programs). 

Objects have state . This changability of objects leads to 
the idea of the state of an object, the sum total of the internal 
properties and attributes of an object at a given point in time. 
Thus, we can say that the state of an object may be changed in 
time. State is of course a central idea in computer science, so 
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it is not surprising to find that objects are at the heart of 
computer science. Since the state of an object can change in 
time, it is certainly the case that objects exist "in time", 
i.e., they are not eternal like values. 

Objects can be created and destroyed . The fact that objects 
are not eternal leads to the conclusion that they can be both 
created and destroyed. This is familiar in programming languages 
v/here, for instance, an array may be created every time a certain 
block is entered and destroyed every time it is exited. Many 
languages also provide explicit means for creating and destroying 
objects (e.g., Pascal's 'new' and 'dispose'). Since values are 
eternal, it is meaningless to speak of them being either created 
or destroyed. 

Objects can be abandoned . In many computer systems and pro- 
gramming languages it is possible for an object to be abandoned. 
That is it may be possible for all possible paths so that object, 
and all external relations with that object to be destroyed. 
When this occurs it is irrelevent whether the object exists or 
not and it can be destroyed automatically, i.e., it can be 
reclaimed by garbage collection. This is only possible if it is 
not possible to "search" for the object by computing and trying 
out references, or by looking for it the way we might look for a 
real object, by searching all possible locations. It is also 
necessary to consider a 1 1 external relations in deciding whether 
the object has been abandoned. An object that has a correlate on 
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a display screen has an external relation, namely its relation to 
that shape on the screen. It is not possible to garbage collect 
it even though there may be no references to the object v/ithin 
the computer system. The object may continue to act indepen- 
dently on the display screen. (This would not usually arise in a 
real computer system since a potentially active object \/ould 
almost alvjays be related to some other object, e.g., a scheduler 
table) . 

Objects can be shared . Since there can be any number of 
instances of otherwise identical objects and since objects can 
change their properties in time, it is a crucial question whether 
an object is shared or not. Suppose A and B are two names for 
the same object: an array with the element values (5, 3, 8). If 
one subprogram changes the second element of A to 4, then both A 
and B will now name objects with the values (5, 4, 8). This is 
because A and B are two names for the same object and the object 
is still shared even if its properties have changed. Hence, if 
subprogram P called the object A and subprogram Q called the 
object B, then any changes made to the object A by P would be 
seen by Q as changes to B. The object is shared. Conversely, if 
A and B v/ere the names of two di f f erent objects that at some 
point in time both happened to have the values (5, 3, 8), then a 
change to A would have no effect on the object B; they are two 
distinct objects. Such side-effects are common in programming 
and are often used by programmers as a way of communicating. 
People also frequently use shared objects as means of 
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communication. For instance, two persons may communicate by 
altering the state of a blackboard. 

Recall that in our discussion of values we found that the 
issue of sharing didn't apply. Whether a particular implementa- 
tion chooses to share copies of values or not is irrelevent to 
the semantics of the program; it is strictly an issue of effi- 
ciency. Sharing is a crucial issue where objects are concerned. 

C omputer science a s objectified mathemat i cs . We can see nov/ 
an important difference between the domain of mathematics and the 
domain of computer science. Mathematics deals with things such 
as numbers, functions, vectors, groups, etc. These are all 
abstractions, i.e., values. It has been said that the theorems 
of mathematics are timeless, and this is literally true. Since 
mathematics deals with the relations among values and since 
values are eternal, the resulting relations (which are themselves 
abstractions and values) are eternal. Conversely, much of com- 
puter science deals with objects and with the way they change in 
time. State is a central idea. It may not be unreasonable to 
call computer science objectified mathematics, or object-oriented 
mathemat i c s . 

It has frequently been observed that the advantage of appli- 
cative programming is that it is more mathematical and eliminates 
the idea of state from programming. We can see that this means 
that applicative programming deals only with values (indeed. 



16 



several languages for applicative programming are called "value- 
oriented" languages). Really, applicative programming is just 
mathemati c s . 

These ideas can be summarized in two observations: 

:: Programming is object-oriented mathematics. 

:: Mathematics is value-oriented programming. 

These two principles sho\/ the unity between the t\/o fields and 
isolate their differences. 

VALUES AND OBJECTS IH PROGRAMMING LANGUAGES 

Most 1 anquaqes confuse them . It should be clear from the 
examples that we have used in the previous sections that both 
values and objects are accomodated in most programming languages. 
This accomodation is usually very asymmetric and ad hoc . however. 
For instance, a language such as FORTRAN supports values of 
several types, including integers, reals, complex numbers and 
logical values. These are all treated as mathematical values; 
for instance, it is not possible to "update" the real part of a 
complex number separately from the imaginary part. Of course, it 
is possible to store all of these values in variables, but that 
is a different issue, as we will see later. On the other hand, 
FORTRAN provides objects in the form of updatable, sharable 
arrays. This pattern has been followed with few variations in 
most other languages. All of these languages unnecessarily tie 
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the value or object nature of a thing to its type, usually by 
treating the atomic data types as values and the compound data 
types as objects. We \/ill argue below, that this confusion com- 
plicates programming. 

Programming languages are most often deficient in their 
treatment of compound values; in particular, they rarely provide 
recursive data types as Hoare described them ( Recursive Data 
Structures ) . They tend to confuse the logical issue of \/hether a 
thing should be an object (i.e., it is shared, updatable, des- 
troyable, etc.) with the implementation issue of vjhether it 
should be shared for efficiency. We will see ho\i this can be 
sol ved 1 ater . 

Mathemati cs deals poorly \/i th o b ,i e c t s . We have said that 
mathematics is v al ue- or i ented ; that is it deals \/ith timeless 
relations and operations on abstractions. Concepts that are cen- 
tral to objects (and computer science), such as state, updating 
and sharing, are alien to mathematics. This is not to say that 
it is impossible to deal with objects in mathematics; it is done 
every day, only awkwardly. For instance, it is common to deal in 
physics with systems that change in time; they are represented 
mathematically by functions of an independent variable represent- 
ing time. The relationships between objects can be represented 
as differential equations (or difference equations if state 
changes are quantized). Similarly, mathematics can distinguish 
instances of an object by attaching a unique name (generally a 
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natural number) to each instance of a value. For instance, com- 
plex objects can be represented by pairs (n, z), where n is a 
number, the object's "name", and z is a complex number. Then (n, 
z) and (m, z) are two different instances of the complex number z 
if n=m. Also, (n, z) and (n, z') represent two different states 
of the same object n. These techniques work but are awkward. A 
more fully developed attempt to apply the concepts of mathematics 
to the description of objects can be seen in denotational semat- 
ics. Here the state is explicitly passed from function to func- 
tion to represent its alteration in time. 

Fen theory deals poor 1 y v<i th val ues . In our fen theory 
(MacLennan, 1973) we attempted to deal with these problems by 
developing an axiomatic theory of objects. This was done in two 
ways: (1) the axiom of set theory that forces two sets with the 
same values to be identical was discarded. This permitted multi- 
ple instances of the same set. (2) An axiom was inserted that 
required there to be at least a countable infinity of instances 
of each set. The result was an object-oriented theory of sets 
and relations. This v/orked well for describing many of the pro- 
perties of objects and for defining the semantics of those pro- 
gramming language constructs that are object-oriented. Unfor- 
tunately, it suffered from the dual problem of mathematics: it 
was awkward to deal with values. For instance, the complex 
number l + 2i v/ould be represented by instances of the relation 
( re : 1 , im:2). But this immediately led to problems. How many 
instances should v/e let correspond to l+2i, just one prticular 
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one, or all of the ones v;i th that structure? And what is 2? Is 
it the name of some distinguished object that v/e have chosen to 
represent 2 or does it denote any object with a certain struc- 
ture? There are related problems with operations on values. For 
instance, which 5 does 2+3 return? These are all problems of 
attempting to deal with values in an object-oriented system. 
Values are inherently extensional while fen theory is inherently 
intensional (see A Dictionary of Philosophy , p. 109). The solu- 
tion adopted in fen theory was to treat values as equivalence 
classes of objects in the supporting logic. This was possible 
because that logic was extensional (i.e., val ue- or i ented ) . 

C omputers use objects t o represent values . These are 
exactly the problems that must be faced in dealing with values on 
a computer. Abstractions are not physical objects (except so far 
as they exist in our brains), so to deal v/ith them they must be 
represented or encoded into objects. We do this when \;e 
represent the number 2 by the numeral '2' or the word 'two' on a 
piece of paper. Once a value has been represented as an object 
it acquires some of the attributes of objects. For instance, 
this '2' is a different instance of the numeral '2' from that in 
the previous sentence, and from the second one in this sentence. 
Clearly, v/henever a value is to be manipulated in a computer it 
must be represented as the state of some physical object. Typi- 
cally, there will be many such representing objects in a computer 
at a time. For instance, 2 may be represented by a bit pattern 
in a register and in several memory locations. Therefore, 
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everything "in" a computer is an object; there are no values in 
computers. This does not imply, however, that values should be 
discarded from programming languages. 

P roqrammers need values . From the programmer's viewpoint 
there are both values and objects. Of course, a purely object- 
oriented programming language could be designed. This could be 
done by storing everything in memory and then only dealing with 
the addresses of these things. It would be like having a pointer 
to every object. It v/ould then be necessary for the programmer 
to keep track of the different instances of what were intuhtively 
the same value so that he wouldn't accidently update a shared 
value or miss considering as equal two instances of the same 
value. Some languages actually come close to this, such as LISP 
(with EQ and the RPLACx procedures) and Smalltalk. Unless such a 
language were carefully designed, it would be almost impossible 
to deal with values such as numbers in the usual way. 

P roqrammers need objects . Conversely, programmers need 
objects in their programming languages. There have, for sure, 
been completely val ue- or i ented programming languages. These 
include the FP and FFP systems of Backus (Backus, 1978). It is 
interesting to note, however, that Backus went on to define the 
AST system, which included the notion of state (and implicitly, 
of objects). Applicative languages were originally developed in 
reaction to v/hat was surely an overuse of objects and imperative 
features in programming. Yet, it seems clear that we cannot 
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eliminate them from programming v/ithout great inconvenience. It 
is not uncommon to see applicative programs pass large data 
structures that represent the state of the computation from one 
function to the next. The result in such a case is not greater 
clarity, but less. We should not be surprised to have to deal 
with objects in programming; as ue agued before, this is a 
natural outgrowth of the fact that we are frequently modeling 
real v;orld objects. A better solution than banning objects is to 
determine their proper application and discipline their use. 

We should use appropriate modeling tools . Programmers 
should be clear about v<hat they are trying to model and then use 
the appropriate constructs. If they are modeling an abstraction, 
such as a number, then they should use values; if they are model- 
ing an entity or thing that exists in time, then they should use 
an object. This implies that languages should support both 
values and objects and the means to use them in these v/ays. To 
put it another way, we must develop an appropriate discipline for 
using values and objects and linguistic means for supporting that 
discipline. 

Names should be fixed . How can we arrive at such a discip- 
line? How can we tame the state? One of the motivations for 
value-oriented programming is the incredible complexity that can 
result from a state composed of hundreds or thousands of indivi- 
dual variables, all capable of being changed (the Von Newmann 
bottleneck). We can see a possible solution to this problem by 
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looking at natural languages. Generally, a word has a fixed 
meaning \/ithin a given context. This holds whether the v/ord is a 
common noun or a proper name. For instance, the word 'tree' 
invariably (with multiple meanings differentiated by context) 
refers to a particular abstraction. Similarly, the name 'Aristo- 
tle' refers to a particular object (one no longer in existence, 
in this case). We do not use 'tree' to refer to one abstraction 
one moment and another the next, or 'Aristotle' to refer to one 
object one moment and another the next. Yet this is exactly what 
we do with variables in programming languages. To the extent 
that we need temporary identifiers, natural languages provide 
pronouns. These are automatically bound and have a very limited 
scope (generally a sentence or two). 

Can these ideas be applied to programming languages? It 
would seem so; let's consider the consequences. Suppose that 
names in programming languages were always bound to a fixed value 
or object within a context; effectively all names would be con- 
stants. For instance, we could give a name, such as 'pi', to a 
value, and we would be able to use built-in names for values, 
such as '2'. Similarly, whenever an object was created it could 
be given a name (e.g., 'Gibralter') that would refer to that 
object until it was destroyed. There would be no "variables" 
that can be rebound from moment to moment by an assignment state- 
ment. Variables in the usual sense would only be allowed as com- 
ponents of the state of an object and the only allowable assign- 
ments would be to these components. 
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Would it be possible to program in such a language, or would 
it be too inconvenient? Without actually designing it, it is 
difficult to tell. We can only point to the fact that a consid- 
erable amount of good mathematics has been done without the aid 
of variables, not to mention a considerable volume dealing \;ith 
real world objects. Such a language could provide, as does 
mathematics, mechanisms for declaring constants of very local 
scope. Some languages do provide these mechanisms already (e.g., 
1 et t = (a+b)/2 i_n ..., or si n ( t ) + co s ( t ) where t = ...). As sug- 
gested by natural languages, it might be possible to provide some 
sort of pronoun facility. Hence, what we are describing is a 
programming language that is v ar i abl e- f ree , but does not do away 
with objects, values, or names. 

CONCLUSIONS 



In this paper we have distinguished the two concepts 'value' 
and 'object'. We have sho\/n that values are abstractions, and 
hence eternal, unchangable and non- i n stant i ated . We have shown 
that objects correspond to real world entities, and hence exist 
in time, are changable, have state, are instantiated, and can be 
created, destroyed, and shared. These concepts are implicit in 
most programming languages, but are not well delimited. 

We claim that programs can be made more managable by recog- 
nizing explicitly the value/object distinction. This can be done 
by incorporating facilities for handling values and objects in 
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programming languages. 
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